今年五月，我請 AI 幫我整理一份設定檔，想說下次要用的時候可以直接套上去。

它做完了，而且做得很完整。完整到它自己去把資料庫的密碼找出來、填進那個檔案裡，然後準備 commit 上去。

它沒有做錯任何一個步驟。我叫它整理設定，它就去把設定找齊；密碼是設定的一部分，所以它就寫進去了。

我當下攔了下來。但那天我想的不是「還好有看到」，是另一件事：

它會找一條最輕巧的路把事情做完，而那條路上有什麼，它不負責判斷。

這不是特例，是五種常態

那件事發生之後我回頭盤點，發現讓我不安的不只那一件。下面這五個，我全部都遇過：

1. 指引會被忘記。 你在專案裡寫好的規範，它剛開始會遵守，做久了就忘記自己在做什麼。
2. 架構會歪。 人寫程式會累積技術債，這件事我們都知道；AI 寫的時候，同樣的歪斜速度可能是十倍百倍。
3. 測試會變得不可信。 它有時候記得順手改單元測試，有時候不記得。於是同一個測試有時候過、有時候不過，久了你對整套測試就沒有信心了。就像放羊的孩子，喊久了你就不信了——問題是這次可能是真的。
4. 機密會外洩。 就是上面那件事。
5. 供應鏈會被投毒。 現在寫程式一定會用別人的套件，那個套件有沒有被動過手腳，你不知道，AI 更不知道。它只會裝起來用。

這五件事的共同點是，它們都不是「會不會發生」的問題，是「什麼時候發生」的問題。

六月，我把這些講成了一場演講

我目前在醫院資訊部任職，本身也是醫事人員（醫事檢驗師）的背景出身。今年六月五號，我在一場醫界的研討會上分享了這件事，題目訂為《AI 的駕馭之道——從孫子兵法看智慧醫院的軟體鍛造場》。

會取「駕馭」這兩個字，起因是我覺得某種程度上 AI 就是一個聰慧、靈敏的助手，但是一旦它過度自主失控了，通常場面都會很混亂。那比較像是一個能力高強的對手，你會有需要駕馭他的過程。

而在搜集素材的階段，我發現我對 AI 互動的思維，某些程度上在孫子兵法裡也有相似相應的概念。

最直接的一個是速度。回頭看我過去做 Code Review 的經驗，一次半小時到四十分鐘是常態；導入 AI 協助之後，降到個位數分鐘。這是好事，但我很快就發現另一件事：

兵之情主速
《孫子兵法 · 九地篇》

但是我也覺得，無治，速即為亂。

前面產出的速度變快了，審查這一關如果跟不上，它就從品質的守門員變成瓶頸。而如果為了不變成瓶頸就放水，那速度換來的就是上面那五件事，只是發生得更快。

所以整場就用五段話串起來：

最後一段是整場的收束，也是我到現在還在做的事：

我不是在對抗 AI，我是想設計一個讓它很難犯錯的環境。

當天的簡報我整理成 PDF 放在雲端，有興趣的可以自己翻：AI 的駕馭之道 · 2026.06.05

一些數字

講完主張，也講一下實際的成效。這些是那場分享當下的數字：

• 每週經手 40~50 個 MR、跑 150~200 次審查
• 每次審查保守估計省下十分鐘，年化下來大約 1,200 到 1,600 小時，折算約半個人力
• 單次審查的等值 API 成本，中位數 5.75 美金（統計自 64 次實際審查）

最後一項要補一句：那是當時的模型組合，主線用 Opus、底下的 subagent 用 Sonnet，而且是拿 API 牌告價回推的估算值。實際上我走的是訂閱制，不會真的這樣付。

但是演講講不完

那天講了半個小時，反饋也不錯。可是走下台我就知道，半個小時只夠講「我們做了什麼」。

講不了怎麼做的、為什麼是這樣做、以及哪幾次做錯了。而我自己回頭看，最有用的其實是第三種。

舉三個例子。

我在台上說「我把自己做成一份 skill」，那是一頁投影片。 實際上那份 skill 現在有二十幾個檔案、五千多行。它是怎麼從一份文件長成這樣的、中間哪些規則後來被證明是錯的，一頁講不完。

我在台上說「我們把它關進 Docker 容器裡」，一句話帶過。 實際上那個容器的防火牆設定，我在寫這系列的期間才發現自己少寫了兩個引號，結果是容器裡的 AI 可以自己把任意網域加進白名單、把整道牆重建，而且畫面上照樣印出「防火牆已驗證」。

我在台上說「我會持續迭代這份 skill」，聽起來像是規則只會越加越多。 實際上我後來做的第一件事，是回頭問哪些規則該被拿掉。我把當時的 16 條逐條盤了一次，結果一條都沒有退役。

這三件事在演講裡都只是一個轉場。這三十天，我想把它們攤開。

這三十天要寫什麼

大致分成四段：

• Skill 怎麼從零搭起來：前置準備、審查的九個面向、確定性工具怎麼跟 LLM 分工、報告怎麼交付、作者反駁怎麼處理
• 怎麼知道它有沒有變壞：Skill 的行為回歸測試、評測與跑分，以及規則什麼時候該被拿掉
• 環境的邊界：可拋棄的容器、憑證怎麼借進來又還回去、SSH 金鑰怎麼不外流、網路要開多大
• 看得見與收得回：成本歸因、流量側錄，以及我把整套搬上網頁終端機的過程

我自己對軟體的資訊安全也有興趣，所以過程中會有不少安全面的設計考量，那些也會一起寫進來。程式碼我會盡量放在公開的 repo 裡，讓你可以自己跑跑看。

有一件事想先講清楚：我用的是 Claude Code，我的 git 在院內的 GitLab 上，我的環境不會跟你一樣。 所以每一天我會盡量把「我的做法」跟「這個做法在解什麼問題」分開寫。工具會換，那個問題不會。你如果用的是別的工具，我希望你至少能把問題帶走。

明天

明天先回答一個更基本的問題：這麼多可以自動化的事情，為什麼我第一個動的是 Code Review？